Many medium and large enterprises rely on business-critical applications to manage their key business processes. Examples of these types of applications include solutions for Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Supplier Relationship Management (SRM), Supply Chain Management (SCM), Product Life-cycle Management (PLM), Human Capital Management (HCM), Business Intelligence (BI), and Integration Platforms, among others. Industry-recognized software products in this area may typically involve SAP NetWeaver-based solutions and the SAP™ R/3 platform, Oracle E-Business Suite, JD Edwards Enterprise One, PeopleSoft, Siebel and Microsoft Dynamics. These products are used in most of the Fortune-100 and large governmental organizations worldwide. SAP™ alone has more than 90,000 customers in more than 120 countries.
In this context, enterprises need to impose internal control mechanisms on, for example, key business functions such as financial transactions, sales, purchases, and supply-chain management, and technical activities such as creating users and granting permissions, amongst others, to prevent fraud, errors, and abuse while also enforcing accountability over the actions each of the users is allowed to perform and the data they are allowed to access while interacting with these business-critical applications. In particular, enterprises need to be aware of a scenario where the performance of a first authorized action by an individual creates a conflict with a second action that would otherwise be authorized for that individual, but for the performance of the first action by the individual. These controls are commonly referred to as Segregation of Duties (SoD for short). There are multiple tools and products that aid the enterprises in the process of defining and checking conflicts in the permissions assigned to users, some of them are: SAP GRC, Virsa, BizRights and INFOR from Approva, Deloitte eQSmart EdeX, Oracle Application Access Controls Governor for E-Business Suite, Saxaflow for SAP™, AuditBot for SAP™, and AllOut Security for JD Edwards, among others.
Current tools and applications that aid the enterprise in the task of SoD are used in the context of a project which may last, for example, from three to six months depending on the organizational maturity and whether the process is recurrent or performed only once. The objective of these projects is to check the permissions assigned to users by checking them against what is commonly known as the incompatibility matrices (or SoD matrices). These express the incompatible permissions/roles inside the business-critical applications, in the context of the analyzed organization. They are based on some pre-built models populated with conflicts that are common for a given platform (such as SAP™ or Oracle™ environments) for the organization. The process itself involves two steps:
First, the process is customized according to the business processes and users of each organization, also taking into account customizations to the audited business-critical applications such as custom transactions and reports (in an SAP™ environment) or custom programs (in Oracle environments). This is why the process typically has a three to six month duration. Second, the permissions for every single user are extracted from the business-critical applications and then the matrices are filled. After these steps have been completed, an analyst proceeds to process the information obtained and reporting all the incompatibilities that should be fixed.
The current state-of-the-art in the SoD practice presents some shortcomings that are key to the prevention and detection of potential frauds, errors and abuse of permissions. The SoD process is one of a static nature, such that once all the necessary information has been gathered, that information only shows a snapshot of the current status of the organization at the time when the information has been collected.
To better illustrate this problem, suppose company A performs a complete SoD analysis over its business-critical applications which lasts 3 months to be completed. By the end of the project, and since user permissions are dynamically changing every day, the violations detected based on the information collected originally might not be present any more, and new conflicts that could be generated by this dynamic change during the project's life might be overlooked by the analyst performing the SoD process.
Some existent tools try to tackle this problem either by periodically checking permissions of users, or by analyzing the access to sensitive data, which is defined in advance. Both approaches present weaknesses. Every periodical check of users' permissions still leaves a window where permissions can be granted and removed. On the other hand, defining sensitive data heavily relies on each organization's responsibility and is subject to misconfigurations and even omission by the employees defining this. At the same time there is a lack of a general approach independent from the audited platform, requiring instrumentation of every kind of user access, different between different vendors.
In view of the shortcomings discussed above, there is a need to overcome the drawbacks of the conventional techniques.